(レポート)SRE Tech Talks 第1回 #sretalks

quiver

2016.08.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本記事は2016年7月25日(月)に開催された SRE Tech Talks #1〜Site Reliability Engineeringにまつわるエトセトラ)〜のレポート記事です。

SREは”Site Reliability Engineering”の略です。SREの概念を広めたGoogleでSREチームを作った Ben Treynor Sloss は SRE のことを次のように定義しています。

"Fundamentally, it's what happens when you ask a software engineer to design an operations function”

https://landing.google.com/sre/

日本で SRE の名前が広まったのは Mercari の2015年11月18日の次のブログがきっかけとよく言われます。

インフラチーム改め Site Reliability Engineering (SRE) チームになりました

本レポートでは、イベントの中から、筆者が特に面白いと思った、次の2発表を中心にレポート致します。

株式会社メルカリ - SRE 長野雅広 @kazeburo Hybrid Server Architecture
株式会社はてなシステム開発本部システムプラットフォーム部倉知真太郎 @dekokun サービス信頼性向上のための事例紹介@はてな

Hybrid SERVER Architecture in Mercari

トップバッターは会場を提供しているメルカリ @kazéburo さんによる発表です。

Mercari の SRE メンバー

Mercariのエンジニアブログで「インフラチーム改め Site Reliability Engineering (SRE) チームになりました」のブログエントリを書いてから、日本で”SRE”という用語が定着してきた

SRE は Google が発祥

OperationsとSoftware Engineeringをやっている

MercariでのSoftware Engineering 例

Gaurun(プッシュ通知サーバ)の開発
ngx_luaのBalancer拡張
ChatOps
Mackerel Plugin開発

Infrastructure

前提として、サーバー群は日本とアメリカにある。

イギリスも展開予定。

日本:さくらインターネット

さくらインターネットの専用サーバ(Metal as a Service)とクラウド

2コアで済むようなサーバであればクラウドを利用
MySQLは専用サーバでioMemoryがささっている

アメリカ:AWS

AWS US West(Oregon)

基本的に全部EC2
マネージド・サービスは基本的に使わない

特徴

クラウドと物理サーバというHybrid Architectureでありながら構成がほとんど同じ理由

アプリケーションコードの複雑性(クラウド・物理の分岐など)を排除したい。

複数サイトあるときに全く同じ構成にして条件分岐を極小にするの、運用に超効くので絶対守ったほうがよい #sretalks

— tagomoris (@tagomoris) July 25, 2016

クラウド・物理それぞれで固有のベースセットアップを済ませたら、そこから上は同じようにプロビジョンしたい

クラウド・物理と同じアプローチでスケールさせたい。クラウドのマネージドサービス(たとえば AWS RDS)を使うと、カスタマイズ出来る範囲が狭くなってしまう。

技術の変遷

最初から、マネージド・サービスを使わず、サーバを並べるアーキテクチャーだったわけではない。

たとえば、スキーマ変更の際、スレーブから先にスキーマ変更し、最後にレプリケーションで利用するbinlogを無効にしてマスターでスキーマ変更する Rolling Schema Upgrade(RSU) を採用したいが、RDS MySQLでは使えない、というような制約が積み重なり、マネージドサービスからサーバ中心のアーキテクチャ(Server Architecture)に変遷してきた。

Server Architectureの理由

新しい技術への対応、スケーラビリティの制御、細かいチューニングと言った理由もあるが、さくらの専用サーバ・クラウドを利用してる日本で大規模に運用しているので、同じ手法をUSでも適用したい、というのが大きい。

AWSのマネージドサービスに統合しない理由

サーバから自分たちで最適化を積み重ねることで、クラウドのマネージドサービスより高い信頼性をSREが提供できる

ただし、信頼性の提供が難しかったり、どう考えてもクラウドのほうが便利な場合はクラウドサービスを使う。

利用しているクラウドサービス例

Akamai(CDN)
Google BigQuery
Mackerel(Monitoring)
SendGrid(メール送信。USだけ)
Route53(DNS)
S3(Storage)

Consul

サーバアーキテクチャを支える技術としてConsulの紹介。

Mercariでは以下の用途で利用。

サービスディスカバリ
- サービスのチェックスクリプトをいろいろ書ける
- $consul maintを使うと、即時にサービスから外すことができる。再起動をしても、メンテナンスモードは維持される。ELBは時間がかかる。
設定の配布
- 2016/08/1のConsul Casual Talks #1 で @cubicdaiya さんが発表。
分散ロック

Mackerel

3年前に Mercari がサービス開始されてから Zabbix をずっと使ってきた。最近 Mackerel に移行した。

移行の背景

JP/USそれぞれでZabbix サーバをインストールしており、バージョンが微妙に違っていた。
監視ホストを追加するとき、管理画面からポチポチやっていると、設定が微妙に異なったりしていた。

これらを整理するために、より信頼性の高い Mackerel に移行した

JP/US で統合的に監視できるようになった。

2016年5月12日には Mackerel Meetup #7 Tokyo を Mercari オフィスで開催した

まとめ

Mercariのシステムは物理サーバを中心としたJP環境とかそうサーバを中心としたUS環境のHybrid Architecture
サーバを中心とした構成で、SREが高い信頼性を提供
Hybrid Server Architecture を支える技術として Consul や Mackerel 等がある

Q&A

# SREチームにとって、ダウンタイムの管理は重要。どうやってダウンタイムを計測している?

ダウンタイムの目標値はあるが、それほど数値にこだわっているわけではない。

Mackerel にはダウンタイムを積算する機能はないので、自分たちで手計算してスプレッドシートで管理するといったことはやっている。

なお pingdom はダウンタイムを計測出来るようです。

# RDS などのクラウドサービスを使わず、自分たちで頑張るServer Architectureを押しているのに、ZabbixをやめてMackerelにした理由は?

監視システムは自分たちのコアコンピタンスではない。

SMTPサーバを管理したい人はどこにもいないから、SendGridを利用している。

Zabbixの運用もサーバ台数が100台を超えてくると大変になるので、外部サービス(Mackerel)にまかせると、自分たちのより重要なサービスにリソースをさける。

印象

マネージド・サービスより高水準なサービスをサーバーアーキテクチャーで提供できているのは、優秀なSREエンジニアが6人もいるMercariだからこそです。

普通のインフラエンジニアが少数しかいない環境では、素直にクラウドのフルマネージドサービスを活用しましょう。

今でこそEC2だらけのAWSインフラも、当初はマネージドサービスで運用していました。

Introducing in-house PaaS

スマートニュース株式会社でSREのマネージャーをやっている尾形暢俊さんによる発表です。

Introducing in-house PaaS in SmartNews from Nobutoshi Ogata

はてなでのサービス信頼性向上のための取り組み事例 by dekokun

続いて、はてな東京オフィスでWebオペレーションエンジニアをやっている id:dekokun さんの発表です。

SREってそもそもなに？

イベント名は”SRE tech talk”だが、SREが何なのか知らなかった。社内で”Site Reliability Engineering”(以下「SRE本」)の輪読会を始めた。

伝統的には

インフラ担当の”Opsエンジニア”
開発担当の”Devエンジニア”

の2種類の職種があるが、はてなでは両者の境界はあいまい

サービス向上のために取り組んでいることの紹介

DevとOpsの対立

SRE本では新しい機能を試したい Dev とシステムを安定させたい Ops の対立が、あるある問題として取り上げている。

はてなでは両者は協力体制にある。

Opsエンジニアがサービスコードをいじり、DevエンジニアがChefをいじる

協力体制事例：DBの転送量削減

クライアント↔DBの通信量が限界に近づいてきた時に、

SRE本では、従来のOpsエンジニアは可用性を守るために素早いデプロイなどに対立するとあるが、Webサービスを提供する側からすれば、問題があった時にさっさとデプロイしないとサイトの可用性は守れない。

OpsがMySQLサーバとの通信データを圧縮するオプションを有効にしたり(DBD::mysql の mysql_compression=1)、 DevとOpsが強力してMySQLサーバとの通信量が増える原因を突き止め、Devが通信量を減らすようアプリ改修したりする。

エンジニアが参加する週次の社内勉強会では、Dev/Opsそれぞれの仕事の内容を発表するなどして、相互理解の助けになっている。

はてなでは日々OpsエンジニアとDevエンジニアが協力しつつ、サービスの信頼性向上への取り組みを行っていっている

コードと検証によってサービスの信頼性を向上させる話

SRE本によると、GoogleのSREチームはオペレーション業務は50％に止め、残りはコーディングに当てる。はてなのOpsチームは、50％程ではないにしてもコーディングでインフラのエンジニアリングをしている。

ミドルウェアの設定ファイルの構文チェッカをさくっと書いたり、インフラ構成を変更するプログラムをさくっと書いたりする

目指すべきシステムの姿について

機械ができることは機械にやらせ、人間は人間にしかできないことに注力する

具体例としてはてなの自動復旧システムが紹介されました。

例えば、Xenの上で作られた、サービスにおいて、DomU で動作しているサービスがヘルスチェックに引っかかったら、DomU をOSごと作りなおす。ヘルスチェックにバンバン引っかかっても、作りなおせば良い。

勝手に復活するやつは実際にはごく一部のどうしようもないところだけいれてます #sretalks

— ゆううき (@y_uuk1) July 25, 2016

まとめ

Dev エンジニアと Ops エンジニアが協調してよりよりサービスを作る。機械にできることは機械にやらせる。

Q&A

AWS Elasticache Redis のようなマネージド・サービスを使わない理由は?

データセンターと同じように運用したい。 (Mercariと同じ理由)

金曜日にリリースしない理由は?

業務時間内で障害対応できるように、夕方以降や土日のリリースを避ける。

DevとOpsの領域は?

曖昧でエンジニアの興味範囲次第。

実践！マイクロサービス化

最後は Wantedly株式会社リードエンジニア相川直視 @awakia さんによる発表です。

個人的印象

終始、楽しそうに発表する姿が印象的でした。

はてなの人、とても楽しそうな話し方が印象的で良い職場感すごい感じた。 #sretalks

— Hiroaki Sano (@la_luna_azul) July 25, 2016

採用目的のイベントではありませんが、エンジニア採用という観点では、非常によい発表だったのではないでしょうか。

なお、はてな様は近日中に自社イベントを開催されるそうです。

SRE の採用について

イベント全体を通しての最後の質問は SRE の採用についてでした。

直球です。

なんでもこなしてしまう SRE メンバーを雇うハードルは非常に高いのではないかと?

質問「SRE雇えるんすかｗｗｗ」 #sretalks

— Ryuta Kamizono (@kamipo) July 25, 2016

各社の回答をまとめます。

メルカリ

メルカリは積極的に採用を続けている。
知り合い経由のオフラインでの採用に力を入れている。
全部で6人いる。
SREは見方によってはコストセンターになる
事業責任者や経営者の理解が必要。
SREからも理解してもらうように働きかける事が必要。
今回の様なイベントを今後も続けることで、SREの活動を世に広め、採用にも繋がるのではないか。

Wantedly

インフラ要項の募集要項に「SRE」のキーワードを増えると、募集が増える傾向がある。
少しバズっているのかもしれない。

はてな

はてなにはSREという名前はない
Webオペレーションエンジニアを積極採用中。
東京に拠点があったり、そもそも、採用募集中であることがいまひとつ認知されていない。
自社セミナーで認知度を上げるようにしている。

スマートニュース

SREチームができたのは2016年1月。
その時から、SREチームはずっと2人。
募集をかけているが、メンバーは増えていない。
SREを名指しで募集してきた人は非常に少ない。
本気で採用するなら、身内から引っ張ってくこないかもしれない。
そもそもスマートニュースは面接の数が多く、内定率は非常に少ない。認知度がまだ低いのかもしれない。

まとめ

私自身は SRE をやる立場にはありませんが、著名サービスを運用する各社のSREチームから生々しい話が聞けて、非常に楽しめました。

SRE チームの職務と言っても、従来のインフラ、オペレーション、DevOps エンジニアのそれと大きく異なるわけではないという印象を持ちましたが、今後は SRE の観点・価値観からサービスのオペレーションがより洗練されていく印象を持ちました。

まずは SRE 本 “Site Reliability Engineering - How Google Runs Production Systems” を読み、SRE の思想を学びたいと思います。

なお、Mercariのオフィスは株式会社ポケモンと隣接しています。

登壇者の皆様、お疲れ様でした！